During Release 12, the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) standard has been extended with support of device-to-device (D2D) (specified as “sidelink” or Proximity Services (ProSe)) features targeting both commercial and Public Safety applications. An example application enabled by Release 12 LTE is device discovery, where devices are able to sense the proximity of another device and associated application by broadcasting and detecting discovery messages that carry device and application identities. Another example application is direct communication based on physical channels terminated directly between devices.
One of the potential extensions for the D2D is support of vehicle-to-anything-you-can-imagine (V2X) communication, which includes any combination of direct communication between vehicles, pedestrians and infrastructure. V2X communication may take advantage of a network infrastructure, when available, but at least basic V2X connectivity should be possible even in case of lack of coverage. Providing an LTE-based V2X interface may be economically advantageous because of the LTE economies of scale, and it may enable tighter integration between communications with the network infrastructure (V2I/V2N), vehicle-to-pedestrian (V2P) communications, and vehicle-to-vehicle (V2V) communications, as compared to using a dedicated V2X technology.
V2X communications may carry both non-safety and safety information, where each of the applications and services may be associated with specific requirements sets (e.g., in terms of latency, reliability, capacity, etc.).
Further LTE-based V2X studies may be desirable due to rapid changes in technology and the market for V2X communication. There are many research projects and field tests of connected vehicles taking place around the world. In China, for example, the China Communications Standards Association (CCSA) finished the feasible study for vehicle safety applications based on time-division (TD)-LTE in 2014, and began a series of industrial standards of communication based on LTE for vehicle applications. In March 2015, the CCSA also started a study on radio spectrum for V2X and some vehicular industrial alliances in China. Based on the study, the National Regulatory Authority in China will allocate the spectrum for connected vehicles.
3GPP SA1#69 recently agreed to new Release 14 studies on LTE support for V2X services: (1) S1-150284, “Proposed study on LTE-based V2X,” LG Electronics Inc., 3GPP TSG-SA WG1 Meeting #69, February 2015; and (2) SP-150051, “New WID for Study on LTE support for V2X services (FS_V2XLTE), from S1-150284,” 3GPP TSG SA Meeting #67, March 2015. The purpose of these studies is to investigate the essential use cases and requirements for V2V, V2P, and V2I/N. V2V covers LTE-based communication between vehicles. V2P covers LTE-based communication between a vehicle and a device carried by an individual (e.g., a handheld terminal carried by a pedestrian, cyclist, driver or passenger). V2I/N (vehicle-to-infrastructure/network), meanwhile, covers LTE-based communication between a vehicle and, for example, a network node such as a roadside unit (RSU). An RSU is a transportation infrastructure entity (e.g., an entity transmitting speed notifications) implemented in an eNodeB (eNB) or a stationary user equipment (UE).
The SA1 study considers both safety services and non-safety services, as well as the possibility of using existing LTE technologies for unicast, multicast, and/or broadcast communication.
More recently, a Release 13 RAN SI has been approved. Its objectives are to evaluate new functionalities needed to operate LTE-based V2X (e.g., V2V, V2I/N, and V2P), and to investigate potential enhancements for vehicular services as defined in 3GPP TR 22.885, v0.2.0, “Study on LTE Support for V2X Services.”
Typical V2X traffic varies greatly in terms of traffic properties, which depend on the specific service being used. For example, packet size and packet periodicity can be very different depending on the service considered. Furthermore, different services are characterized by widely varying radio requirements in terms of, for example, reliability, range and latency. The radio-level behavior should preferably take into account the Quality of Service (QoS) requirements and properties of the traffic in order to optimize performance. The application generating the traffic, however, is generally transparent to the radio layers.
The above problems are known in 3GPP. Existing approaches have attempted to address these problems by defining different types of bearers associated to different applications and types of traffic (e.g., VoIP, best effort, etc.). The V2X traffic, however, is very heterogeneous in terms of requirements and characteristics. Thus, it would result in an impractical number of different bearers if all requirements had to be explicitly supported.
In addition, typical radio systems (e.g., LTE) define different types of nodes with different radio interfaces. For example, the eNB radio interface is different from the interface in a UE. There are also significant differences in the architecture and protocols implemented at different nodes. Mapping between type of nodes and interfaces is no longer respected (e.g., for V2X). For example, a RSU is a network node that can be implemented in various ways. The radio layers may, for example, use either the same interface as an eNB or as a UE, depending on deployment choices. In the case of a UE-type interface, for example, the behavior of the radio layers may be different from the behavior expected from a UE used as a car. Similarly, UEs may even be mounted on cars, or used as handheld devices performing V2X services. Even in these cases, the specified radio interface is supposed to act differently depending on the type of node implementing it.
The Intelligent Transport Systems (ITS) application layer is standardized in ETSITS 302 637-2, “Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service,” November 2014. As standardized, the application layer would generate packets of various types in different dimensions: 1) the variation of traffic type: as stated in section 2.1, V2V, V2I (and I2V) and V2P (and P2V) traffic may be generated by the same ITS application layer; and 2) the variation of traffic periodicity: for the ITS application layer, two of the key/typical application messages are the Co-operative Awareness Message (CAM) and Decentralized Environmental Notification Message (DENM). The two messages are generally generated in a time-varying way. For a CAM message, the default generation time is one message per second, but temporarily additional messages can be generated more frequently (for which the maximum frequency is 10 Hz) due to, for example, position change, speed change and/or direction change. A DENM message is always an event-triggered message. Considering the different categorizations above, to secure QoS for different packets it is necessary that the access stratum treat each packet from the application layer in a different way.
In Release 13, ProSe Per-Packet Priority (PPPP) is proposed as a means to provide priority for ProSe communication as described in 3GPP TS 23.303 v13.1.0, “Proximity-based services (ProSe).” The main functionality of this feature can be described as follows. PPPP is a scalar value associated with a protocol data unit (PDU) that defines the priority handling to be applied for transmission of that PDU. The ProSe Per-Packet Priority is independent of the Destination Layer-2 ID, and applies to both one-to-one and one-to-many ProSe Direct Communication. PPPP in Release 13 is defined only for ProSe communication via PC5 (the reference point between ProSe-enabled UEs used for control and user plane for ProSe Direct Discovery, ProSe Direct Communication and ProSeUE-to-Network Relay) and the bearer mapping between PC5 and Uu (the radio protocols of E-UTRAN between the UE and the eNodeB) for UE-NW relay. There might be a mapping between priority and the ProSe communication resource pool, with the details on the mapping for further study. Therefore, PPPP enables some kind of QoS. It is limited in some aspects, however, and thus not satisfactory for the V2X scenario.